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ABSTRACT: The labyrinth of interoperability policy can present many obstacles to unwary, unsuspecting C4I 
(Command, Control, Communications, Computers, Intelligence) or M&S (Modeling and Simulation) system developers 
and users. This paper provides a roadmap to help weary developers and users find their way through this complex, 
confusing, and often frustrating maze of policies. 


1. Introduction 

The purpose of this paper is to provide a roadmap of 
interoperability policy for C4I and M&S system devel¬ 
opers and users. First, however, it is necessary to de¬ 
fine the concept interoperability. Interoperability has 
been previously defined as: 

“The ability of the systems, units, or forces to provide 
services to and accept services from other systems, 
units, or forces, and to use the services so exchanged to 
enable them to operate effectively together. The 
conditions achieved among communications-electronics 
systems or items of communications-electronics 
equipment when information or services can be 
exchanged directly and satisfactorily between them 
and/or their users. ’ ’ [1] 

“The ability of a model or simulation to provide 
services to and accept services from other models and 
simulations, and to use the services so exchanged to 
enable them to operate effectively together. ” [2] 

One can infer then, that there are at least two different 
perspectives of interoperability, the systems 
perspective and the simulation perspective. Put 
another way: 

“Truth is that which serves the interests of a people. 
Two groups of people locked in combat cannot be 
expected to have the same truth. ” 

— Albert B. Cleage, Jr. 


Is interoperability a problem? One of the first and 
most poignant examples is taken from Operation 
Urgent Fury, the battle of Grenada, in 1983: 

“MG Trobaugh, Commanding General of the 82nd 
Airborne Division, was a very frustrated commander 
throughout the effort, not only at communications, but 
at the entire C2 structure. From the outset of the effort 
the 82nd Airborne was slow to respond to commands 
from the overall task force commander. Admiral 
Metcalf, headquartered on the ship Guam. At one 
period MG Trobaugh landed on the island and tried to 
effect coordination with Admiral Metcalf, anchored less 
than ten miles away. Problems ensued due to radio, 
COMSEC, and frequency incompatibility that did not 
allow the land-based commander to talk to the overall 
command headquarters, something that proper J6 
planning and coordination should have prevented. MG 
Trobaugh could see the ship anchored only a few miles 
away but could only talk intermittently via a satellite 
link. ’’ [3] 

O.K., interoperability was a problem, but is it still a 
problem? Some very recent disturbing findings [4] 
indicate that while some progress has been made, very 
serious C4I interoperability problems remain unsolved: 

“First, future naval coalitions involving the U.S. will be 
stratified into groups of nations, based on C4I 
interoperability, with gaps between groups. Not all 
nations will be able to take on all missions. 

We found that interoperability is likely to be poor for 
the Joint Planning Network, in part because of the 
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allied navies ’ shortage of SATCOM bandwidth relative 
to the U.S. Navy and the proliferation of both U.S. and 
allied systems. Interoperability of sensor-to-shooter 
networks is also expected to be poor, because of the 
U.S. near-exclusive hold on most systems of this type. 

The Navy, however, does not have a coherent gameplan 
to promote combined C4I interoperability or to specify 
how different initiatives should be prioritized. Nor does 
it have any developed doctrine and procedures on using 
advanced information technology specifically for 
working with allies ” 

So interoperability is a problem, but what does policy 
have to do with it? Why is interoperability policy im¬ 
portant? Interoperability policy defines the what, who, 
why, and where of interoperability programs. It defines 
what actions will be taken, who is responsible for them, 
why they must be taken, and where they’re to be per¬ 
formed. Interoperability plans and procedures add the 
how and when, in that they define processes for per¬ 
forming the actions and provide schedules for their 
completion. Some people have the mistaken notion 
that interoperability policy doesn’t matter, that it 
doesn’t have any effect on the actual achievement of 
interoperability. Instead, these individuals believe that 
only technology factors have an effect on achieved 
interoperability. Nothing could be further from the 
truth, as evidenced by this very recent policy statement: 

“Interoperability will be a key determinant in the 
acquisition of new weapons and a greater set of 
interests will be brought into the decision making 
process. There will also be a single focal point to 
coordinate all interoperability activities. 

With the start of the new fiscal year on 1 October, the 
DoD acquisition officials will begin considering 
interoperability as a "key performance parameter" in 
the development of individual weapon systems and 
military equipment. For the first time equipment will be 
fielded in part to achieve commonality with the 
equipment of other US military services or allied 
capabilities. 

‘Weapons will be judged by their ability to 'plug and 
fight',’ said Vitali Garber, the DoD's director of 
interoperability - a position recently created by DoD 
acquisition chief Jacques Gansler as a central authority 
for interoperability. ” [5] 

Similarly, M&S project funds can be withheld, or per¬ 
mission to play with other simulations denied, because 
a simulation is not HLA(High Level Architecture)- 


compliant - things that are required by DoD 
(Department of Defense) interoperability pohcy[6]. 

2. The Policy Conundrum 

Now that we’ve established that interoperability is a 
problem, that it’s important, and that interoperability 
policy is important, we can turn our attention to the 
next question, “Is interoperability policy a problem?’’ 
At least one high official within DoD issued a recent 
statement that supports the view that it is a problem: 

“The ‘architecture and management [of the Defense 
Information Infrastructure] have failed to provide the 
security, interoperability and economy originally 
envisioned, ’ Arthur Money, DOD's chief information 
officer, told a joint hearing of the Procurement and 
Research and Development Subcommittees of the 
House Armed Services Committee. ” [7] 

The labyrinth of interoperability policy can present 
many obstacles to unwary, unsuspecting C4I 
(Command, Control, Communications, Computers, 
Intelligence) or M&S (Modeling and Simulation) 
system developers and users. The purpose of this 
paper is provide a roadmap to help weary developers 
and users find their way through this complex, 
confusing, and often frustrating maze of policies. It is 
hoped that this paper will help the reader to better un¬ 
derstand interoperability policy by condensing, com¬ 
paring, contrasting, and presenting the basic elements 
of interoperability policy in a form that helps bring 
order, meaning and understanding out of chaos. 

The problem of analyzing interoperability policy can 
best be understood by first viewing it within the 
context of a comprehensive interoperability program, 
as shown in Figure 2.0 [8]. 

3. Method 

Two basic approaches were taken to analyzing 
interoperability policy, automated information retrieval 
& text analysis methods, and manual, semi-automated 
techniques such as the construction of information ma¬ 
trices with spreadsheets. 
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3,2 Manual Analysis Methods 



Figure 2.0 Interoperability Program Architeeture 


3,1 Automated Text Analysis & Infor¬ 
mation Retrieval - SMART 

The technique developed by Dr. Gerard Salton for 
automated information retrieval and text analysis is 
called the vector-space model [9], which is similar to 
an n-space dot product of a vector representing a query 
and a vector representing a document. The elements of 
each vector are words, word stems, and word pairs 
found in the documents. The result of the n-space dot 
product is a scalar value between zero and one, with 
zero being a document pair having no common terms 
and one being a document pair having all (100 percent) 
common terms. A 1.0 scalar value is always achieved 
when a document is compared to itself 

Automated interoperability policy document informa¬ 
tion retrieval and text analysis was performed with a 
freely available and extremely mature software tool 
called System for the Mechanical Analysis and Re¬ 
trieval of Text (SMART), which implements the vec¬ 
tor-space model[10]. 


Five different manual analysis methods were used to 
analyze interoperability policy. Each of these methods 
used intermediate results obtained from the automated 
text analysis & information retrieval tools that were 
used in the interoperability policy study. 

First, a “Top-10 List” of interoperability policy docu¬ 
ments was drawn up from those policy documents that 
had high relevance scores computed by SMART with a 
list of interoperability policy concept terms, which it¬ 
self was made by eliminating very rare (low frequency) 
and very common (high frequency) interoperability 
policy concept terms. Some judgement was also used 
to decide just what or wasn’t a policy document - a 
policy document had to belong to one of three catego¬ 
ries, policy directives, standards mandates, and imple¬ 
menting memoranda. 

Second, interoperability policy statements and element 
were manually extracted from each of the documents in 
the “Top-10 Lisf’ by common text outlining and sum¬ 
marization techniques. 

Third, an Interoperability Policy Roadmap was con¬ 
structed by manually examining each policy document 
to determine its precedence and dependence upon re¬ 
lated policy documents. Directives at higher levels of 
the organization typically spawn related, implementing 
directives at lower levels; with more process details 
being added at successively lower levels. 

Fourth, an Interoperability Policy Element Document 
Presence Matrix was constructed to relate all 
interoperability policy elements to each interoperability 
policy document in the “Top-10 List.” 

Last, a C4I and M&S Systems Interoperability Policy 
Elements Comparison Matrix was constructed by sort¬ 
ing and placing interoperability policy elements side- 
by-side for both the C4I and M&S domains. This ma¬ 
trix made it possible to visually identify the complete¬ 
ness and consistency of interoperability policy in both 
the C4I and M&S domains. 

4. Analysis and Discussion 

The analysis of interoperability policies in both the C4I 
and M&S domains is discussed here. Two kinds of 
analysis results are presented and discussed. 
Automated Text Analysis & Information Retrieval, and 
manual analysis. 
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4.1 Automated Text Analysis & Informa¬ 
tion Retrieval Results 

Analysis results for Document-to-Document Rele¬ 
vance, Document-to-Interoperability Policy Concept 
Term List Relevance, Policy Concept Term List 
Discriminatory Value, and the Document 
Interoperability Policy Concept Term Presence Matrix 
are discussed in the following sections. 

4.1.1 Document-to-Document Relevance 


In Figure 4.1.1 we can see that the following C4I 
interoperability policy documents are strongly related 
to one another (document-to-document relevance be¬ 
tween 0.6 and 0.8), with the bolded policy directives 
being strongly related to more than one other direc- 
tive[ll, p. D-1]: 


Top-10 Interoperability Policy Documents 
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Figure 4.1.1 Document-to-Document Relevance 


♦ DoDD 4630.5, C3I Interoperability 

♦ DoDI 4630.8, C31 Interoperability Procedures 

♦ CJCSI6212.01 A, C4I Interoperability 

In the M&S domain, however, we see that the top-level 
M&S interoperability policy directive, DoDD 5000.59, 
M&S Management, is strongly related to the following 
policy directives from both domains: 

♦ DoDI 5000.61, M&S W&A 

♦ DoDI 4630.8, C31 Interoperability Procedures 

Interestingly, the directive DoDI 4630.8, C3I 
Interoperability Procedures is strongly related to 
policy directives in both domains. It seems to act as a 
kind of link between the two domains. 


It is also interesting to note that the top Navy M&S 
interoperability directive, SECNAVINST5200.38, DON 
M&S Program, isn’t strongly related to any other 
policy document. 

4.1.2 Document-to-Interoperability Policy 
Concept Term List Relevance 

Table 4.1.2 lists the SMART-computed relevance 
scores for the “Top-10” interoperability policy docu¬ 
ments in descending order[ll, pp. 3-1 to 3-3]. In this 
case, each document was compared to a specific list of 
interoperability policy concept terms rather than the 
more general list of interoperability terms that were 
used to compute document-to-document relevance. 


Interoperability Policy Document 

Policy Concept 
Term Relevance 

Score 

CJCSI 6212.01A, Compatibility, Interoperability, and Integration 
of C41 Systems, 30 June 1995 

0.3040 

DoDI 4630.8, Procedures for Compatibility, Interoperability, 
and Integration of C3I Systems, iSNovember 1992 

0.2988 

DoD Regulation 5000.2-R, Mandatory Procedures for Major 

Defense Acquisition Programs (MDAPs) and Major Automated 
Infomiation Systems (MAIS) 

0.2689 

DoDI 5000.61, DoD Modeling and Simulation Verification, 
Validation, and Accreditation (VV&A), 29 April 1996 

0.2496 

DoDD 4630.5, Compatibility, Interoperability, and Integration 
of C31 Systems, 12 November 1992 

0.2389 

JTA Version 2.0, Sect. 1 

0.2325 

DoDD 5000.59, DoD Modeling and Simulation (M&S) 

Management, 4 January 1994 

0.2305 

SECNAVINST 5200.38, Department of the Navy Modeling 
and Simulation Program, 10 October 1994 

0.1784 

USD(A&T) Memo 10 September 1996, DoD High Level 

Architecture (HLA) for Simulations 

0.1684 

USD(A&T) Memo 30 Nov 1998, DoD Joint Technical 

Architecture (JTA) Version 2.0 

0.1493 


Table 4.1.2 Document-to-Interoperability Policy Concept 
Term List Relevance - The “Top-10” List 


4.1.3 Policy Concept Term List Discrimina¬ 
tory Value 

One of the issues that surfaced during the 
interoperability policy study was the method of select¬ 
ing concept term lists. SMART provides one method, 
which consists of selecting a lower and upper bound to 
the frequency of concept term occurrence within the 
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document database. This is only the starting point 
however. 

As the interoperability policy study’s authors 
caution: 

“In summary, it is important to understand that 
meaningful text analysis using dot product spaces 
requires an iterative process to develop a high-quality 
query. Terms on the detailed term presence tables were 
present in many documents. If those terms have poor 
discriminatory value (i.e., appearing in documents 
known to have dissimilar contents), then they must be 
removed from the queries. 

The fact that the queries themselves were markedly 
similar indicated that the queries required additional 
refinement. Discriminatory value is improved if the 
queries are as orthogonal as possible.” [11, pp. 2- 
14,15] 

An example of the relative discriminatory values of 
four different concept tenn lists is shown in Figure 
4.1.3. 



Figure 4.1.3 Relative Discriminatory Values 
of Four Concept Term Lists 


4,2 Manual Analysis Results Discussion 

Analysis results are discussed in the following 
sections: (1) interoperability policy statement and 
element selection; (2) policy document precedence and 
dependence; (3) C4I and M&S Systems 
Interoperability Policy Elements Comparison; (4) 
policy consistency; (5) policy completeness; and (6) 
policy effectiveness and efficiency. 


4.2.1 Interoperability Policy Statement and 
Element Selection 

Policy elements were manually extracted from policy 
statements found in interoperability documents that 
were highly relevant to the Interoperability Policy Con¬ 
cept Term List. Twenty candidate interoperability 
policy documents were originally selected for analysis 
from the interoperability document database, which 
includes almost seventy different documents. The 
author further reduced this list of twenty documents to 
a “top-ten” list (see Table 4.1.2) by further selecting 
only those documents that could be unambiguously 
identified as being policy-related (a directive, standards 
mandate, or implementing memorandum). 

4.2.2 Interoperability Policy Roadmap - Policy 
Document Precedence and Dependence 

Reviewed interoperability policy documents receive 
their authority and mandate from higher management 
and command authority levels or echelons. This hier¬ 
archy of authority is diagrammed for Navy M&S Pro¬ 
gram Managers in Figure 4.2.2-1, which depicts the 
interoperability policy document precedence and de¬ 
pendence relationships existing within the list of 
interoperability documents having the highest 
relevance to interoperability policy concept terms. In 
most cases, documents with later publication dates 
point to documents written earlier at higher 
organizational levels or echelons. Subordinate 
commands frequently use identical, similar, or related 
names. For example, the Navy Modeling and 
Simulation Master Plan points to the DoD Modeling 
and Master Simulation Plan and succeeds it in its date 
of publication. Figure 4.2.2-2 provides a similar 
roadmap for Navy C4I system program managers; it 
deletes references to M&S interoperability policy 
documents. 

It also adds some specific Navy C4I interoperability 
policy references that are uniquely C4I, but were not 
analyzed or included in the original interoperability 
policy document database. 

4.2.3 C4I and M&S Systems Interoperability 
Policy Element Mapping 

The author independently extracted interoperability 
policy elements from each interoperability policy 
document in the “Top-10 Lisf’ (see Table 4.1.2). 
These policy elements are primarily concerned with 
prescribed policy actions or the “whaf’ of 
interoperability policy; they include very few 
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Defense M&S Initiative 



Figure 4 . 2 . 2-1 M&S Interoperability Policy 



Figure 4,2,2-2 C4I Interoperability Policy 


references to the “who, why, or where.” The policy 
elements extracted by the author are also not the same 
as those extracted by the interoperability study authors 
[11], but they are based upon them. Finally, 
interoperability policy elements are condensed to an 
abbreviated form of short phrases or statements that 
can be easily displayed and sorted in a matrix. 

4.2.3.1 C4I Systems Interoperability Policy Ele¬ 
ment Mapping 


C4I systems interoperability policy elements are 
mapped to interoperability documents in the “Top-10 
List,” as shown in Figure 4.2.3.1. Related C4I systems 
interoperability policy elements are grouped together 
and alternately shaded in gray or white to distinguish 
one conceptual group from another. 

Figure 4.2.3.1 also shows that with one exception, all 
the C4I systems interoperability policy elements are 
confined to six C4I systems policy documents (CJCSI 
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M&S fModellng & Simulation) Systems I I I 
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Accreditation documentation maintained & accessible 








Accreditation procedures by CJCS for Joint federations, M&S 







Accreditation responsibility of M&S application sponsor 


C4I systems all for Joint use 












C4I systems approved interface standards list 










C4I systems information exchange requirements 










C4I systems interoperability requirements list 










C4I systems standardized information flow procedures and formats 










C4I systems, interfacing systems mandatory guidance in TAFIM 










Certification of C4I system operation within Joint interface 










Certification of C4I systems compatibility 











Certification of interoperability requirements by CJCS procedures 










Certification of systems integration 











Combined tests verify interoaerabilitv in combined ODerations 













Common databases developed 








Common tools develo 

ped 





Compatibility development, coordination, review procedures by CJCS 










Compatibility requirements conform to interoperability policy 










Compatibility requirements tested, validated; meet standards 










Compatibility satisfactorily addressed throughout life cycle 










Compatible w/ existing, planned. Joint, allied, combined C4I systems, ops 








Compatible with other C4I systems 











Compliant with U.S. standards and STANAGs 










Consistent fnew systems w/ interoperating systems') standards application 








Data interchange standards ensure that application formats share data 

Data interchange standards ensure that app 

ication formats share data 




Data interchange(exchange) standards & protocols established 





Data verified, validated, and certified 




Dll COE shall be used by C4I systems & M&S systems 

Dll COE shall be used by C4I systems & M&S systems 

Doctrine compatible with interoperability requirements 










Doctrine concepts & operational procedures 

approved by CJCS 










Doctrine concepts & operational 

procedures for Joint and combined oc 

s 














Federation accredidation of Joint M&S and Joint federations 







Federation appearance, behavior, completeness are acceptable 







Federation data exchange is accurate and comparable across elements 






Federation elements can exchange data 









Federation Execution Details Data Interchange Format 

• FED DIF 







Federation performance, fidelity, interoperability are acceptable 







Federaton response times commensurate with use across elements 

Follow-on Test and Evaluation fFOT&E)to assess interoperabilrtv 

1 






HLAv OHigh Level Architecture) mandated for all M&S 








HLA managed by EXCIMS AMG 










HLA supercedes DIS and ALSP 





Human-cornouter interface mandated standards in Appendix B 

Human-computer interface mandated standards in Appendix B 

tncompetibilitv: integration, interoperability problems reported 

II '1 

Information modeling and information mandated standards in Appendix B 

Information modeling and information mandated standards in Appendix B 

Infonnation processing mandated standards 

in Appendix B 



Information processing mandated standards 

in Appendix B 


Information systems security mandated standards in Appendix B 

Information systems security mandated standards in Appendix B 

Information transfer mandated standards in Appendix 8 

Information transfer mandated standards in Appendix B 

Infrastructure access anywhere, anytime, any mission 










Integratable, integrated 












Integrated with Joint, combined C4I systems, operations 










Integration development, coordination, review procedures by CJCS 










Integration requirements tested, validated; meet standards 










Integration satisfactorily addressed throughout life cycle 










Interface standards validated and approved 











Internet 5-laver network model standards prescribed for C4I systems & M&S 

Internet 5-lsyer network model standards prescribed for C4I systems & M&S 

1 

Internet standards and protocols established, followed 

Interoperability complies DoDD 4630.5, DoDI 4630.8, and CJCS 6212.01A 








Interoperability development, coordination, review procedures by CJCS 









Interoperability maintainability assessed during MNS, ORD validation 










Interoperability major consideration each milestone decision point 










Interoperability major decision for MDAP/MAIS start 










Interoperability reqmts consistent with C4I system architectures 










Interoperability reqmts consistent with C4I system integration reqmts 










Interoperability reqmts consistent with C4I system interface standards 










Interoperability reqmts consistent with C4I system procedures 










Interoperability requirements conform to interoperability policy 










Interoperability requirements documented 











Interoperability requirements identified during C4I reqmts validation 










Interoperability requirements meet standards 










Interoperability requirements tested 











Interoperability requirements validated 











InterooerabHity satisfactorily addressed throughout life cycle 
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iMeroperabilitY standards and protocols developed, implemented, followed 

Interoperability waivers not permanent 











Interoperable horizontally & vertically 











Interoperable with allied C4I systems, operations 










Interoperable with combined/muttinational C4I systems, operations 

Interoperable with combined/multinational C4I systems, operations 

Interoperable with existing C4I systems reguiring data exchange 

1 1 1 1 1 1 

Interoperable with Joint/multiservice C4I systems, operations 

Interoperable with Joint/multiservice C4I systems, operations 

Interoperable with planned C4I systems requiring data exchange 










Joint C3I Interoperability Requirements Database with MNSs, ORDs 










Joint tests verify interoperabilitv in Joint operations 










JTA fJoint Technical Architecture) Version 2.0 implemented 

JTA fJoint Technical Architecture) Version 2.0 implemented 

JTA maintained by DISA 

JTA maintained by DISA 

JTA mandated standards for emerging, existing, planned capabilities 

JTA mandated standards for emerging, existing, planned capabilities 

JTA reo'd for all capabilities that produce, use. or exchange electronic info 

JTA reg'd for all capabilities that produce, use. or exchange electronic info 

JTA reg'd for all systems that give the warfighter an operational capability 

JTA reg'd for all systems that give the warfighter an operational capability 





M&S No pay date, 10/1/89, all M&S that are not HLA>-compliant 






M&S No plav date. 10/1431, all M&S that are not HLA-compliant 


Mapping, charting, geodesy data standards, specs support interoperability 






1 

MNS and ORD complies with interoperabHitv policy 
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Object Model Data Dictionary 









Obiect Model Templal 

e Data Interchange Format - DMT DIF 


Open systems architecture standards and protocols established 

Open systems architecture standards and protocols established 

Operational procedures compatible with interoperability requirements 










ORD includes C4I system communications, protocols, standards 










ORD includes C4I system integration into C4I architecture 










ORD includes C4I system Joint use considerations 










ORD includes C4I system procedural & technical interfaces 










OT&E plans include compatibility, interoperability test objectives 










Recertified when reouired fay hardware or software modifications 
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Seamless, transparent, open systems infrastructure, development 

Seamless, transparent, open systems infrastructure, deyelopment 

Standard data elements shall be exchanged by C4I systems and M&S 

Standard data elements shall be exchanged by C4I systems and M&S 

I 



Standard Simulator Data Base Interchange Format • SIF 


I 



Synthetic Environment Data Representation Interchang 

e Spec - SEDRIS 

Systems design and integration rules for technical architecture 

Systems design and integration rules for technical architecture 


TEMPS include compatibility, interoperability test objectives 

Test & Evaluation (TSf) in all acquisition phases to verify interoperabiWY 


Table 4.2.4 Comparison of Existing C4I and M&S Interop erability Policy 
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6212.01A, C4I Interoperability; DoDI 4630.8, C3I 
Interoperability Proeedures; DoDR 5000.2-R, MDAP 
& MAIS Proeedures; DoDD 4630.5, C3I 
Interoperability; JTA Version 2.0; USD(A&T) Memo 
JTA Ver. 2.0). Virtually none of them eome from 
M&S poliey doeuments. This is what was expeeted 
sinee C4I poliey doeuments deal with issues that are 
eommon to both C4I and M&S, while M&S poliey 
documents are largely confined to M&S issues. 

4.2.3.2 M&S Systems Interoperability Policy 
Element Mapping 

M&S systems interoperability policy elements are 
mapped to interoperability documents in the “Top-10 
List,” as shown in Figure 4.2.3.2. Related M&S sys¬ 
tems interoperability policy elements are also grouped 
together and alternately shaded in gray or white to dis¬ 
tinguish one conceptual group from another. 

A closer inspection of Figure 4.2.3.2 also reveals that 
M&S interoperability policy elements are largely con¬ 
fined to four M&S policy documents {DoDI 5000.61, 
M&S VV&A; DoDD 5000.59, M&S Management; 
SECAVINST 5200.38, DON M&S Program; and 
USD(A&T) HLA Memo). Virtually none of them 
come from the four C4I policy documents. This time, 
however, more than half of the M&S interoperability 
policy elements come from JTA-related 
interoperability policy documents [12] rather than 
M&S interoperability policy documents - this was not 
expected. 

4.2.4 Comparison of C4I and M&S 
Interoperability Policy 

Once both C4I and M&S interoperability policy ele¬ 
ments have been mapped to their respective policy 
documents it is then relatively simple to compare C4I 
interoperability policy elements with M&S 
interoperability policy elements for completeness and 
consistency. Table 4.2.4 provides a side-by-side 
comparison of both C4I and M&S interoperability pol¬ 
icy elements that have been sorted, collated, and 
shaded to clearly show: (1) which C4I 

interoperability policy elements have no counterpart 
elements in M&S interoperability policy documents; 
(2) which M&S interoperability policy elements have 
no counterpart elements in C4I interoperability policy 
documents; and (3) which interoperability policy 
elements are common to both C4I and M&S 
interoperability policy. 


4.2.4.1 Completeness 

Completeness of interoperability policy will be ana¬ 
lyzed and discussed in the context of Table 4.2.4 and 
other policy analysis work performed in the 
interoperability policy study [11]. Table 4.2.4 suggests 
four categories of interoperability policy completeness 
that should be discussed, interoperability policy 
elements that are: (1) in C4I, but not in M&S; (2) in 
M&S, but not in C4I; (3) in both C4I and M&S; and 
(4) not in C4I or M&S. 

4.2.4.1.1 Interoperability Policy Elements in C4I, 
not in M&S 

The following types of interoperability policy elements 
are found in C4I interoperability policy documents, but 
not in M&S policy documents: 

Certification 

Why “certification” is used in the C4I domain, while 
“accreditation “ is used in the M&S domain, is not 
completely clear since the two terms seem to be used 
interchangeably. Certification, for example, is defined 
as “The process by which DOD systems with C4I capa¬ 
bilities is evaluated for satisfaction of requirements for 
interoperability, compatibility, and integration. “ [13, 
p. A-1], while accreditation is alternately defined as 
“The process by which a C4I system is evaluated for 
meeting security requirements to maintain the security 
of both the information and the information systems. ” 
in the C4I domain [13, p. A-1] and “The official 
certification that a model, simulation, or federation of 
models and simulations is acceptable for use for a 
specific purpose." [14, p.8]. The distinction is further 
confounded by the meaning previously given to 
“Certification” in tactical systems software 
development, the endorsement by signature of the 
commanding officer of an operational unit that the 
certified software had been correctly installed, tested, 
and found operationally acceptable in that unit’s 
specific operating environment. 

DISA (Defense Information Systems Agency) has 
certification authority for reporting the interoperability 
of C4I systems, while there is no comparable authority 
for certifying simulations, or simulation-to-C4I system 
interfaces. Certification of the interoperability of M&S 
systems is not explicitly addressed by DoD, Joint, or 
Navy interoperability policies. 
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Compatibility 

Compatibility is defined in the C4I domain as “The 
capability of two or more items or components of 
equipment or material to exist or function in the same 
system or environment without mutual interference. ’’ 
[13, p.A-2], but the term is not used in the M&S 
domain, and there is no good reason why it shouldn’t 
be used there too. A C4I system or a simulation might 
be “compatible” with some other system, but not 
necessarily “interoperable” with it; and the distinction 
is both meaningful and important. 

Doctrine 

Since both C4I systems and operational simulations 
need to faithfully represent the tactical doctrines upon 
which they’re based, this policy element should also be 
included in the M&S domain. This is especially true 
since doctrine is part of the JTA “operational’ archi¬ 
tecture, which is applicable to both C4I systems and 
simulations. 

Integration 

Integration is defined in the C4I domain as “The ar¬ 
rangement of systems in an architecture so that they 
function together in an efficient and logical way.” [13, 
p.A-3] Once again, the meaning of integration, is 
entirely different than the meaning of “interoperability” 
or “compatibility.” C4I systems and simulations may 
be successfully integrated with one another without 
necessarily being compatible or interoperable. Since 
M&S systems are integrated in at least three contexts, 
as information systems themselves, as components of 
C4I and weapon systems, and as C4I/simulation 
interfaces, one should expect their integration to be an 
important part of M&S interoperability policy - but it 
isn’t. 

Interface Standards 

Interfaces are explicitly addressed in C4I 
interoperability policy documents, but not in M&S 
interoperability policy documents. Omission of 
interface standards from M&S interoperability policy is 
an oversight, which may prove increasingly costly as 
simulations are increasingly interfaced with C4I sys¬ 
tems. 

Interoperability Problem Reporting 

C4I interoperability policy requires that incompatibil¬ 
ity, integration, and interoperability problems be re¬ 
ported, while M&S interoperability policy does not. 
Since these same problems also occur between simula¬ 


tions and simulation-to-C4I system interfaces, they 
should also be systematically reported, recorded, and 
tracked. How else can effective actions be planned for 
their resolution? 

Interoperability Requirements 

The only reference to interoperability requirements in 
M&S interoperability policy documents is in the DoD 
M&S Master Plan [15]. M&S interoperability policy is 
noticeably silent on the management, validation, and 
identification of interoperability requirements. The 
lack of early identification of interoperability require¬ 
ments could seriously hamper interoperability when 
models, simulations, C4I systems, and other automated 
systems need to interoperate. C4I interoperability pol¬ 
icy, on the other hand, provides significant coverage of 
interoperability requirements. Explicit references to 
maintenance of interoperability requirements are found 
in C4I interoperability policy documents. 

Interoperability Testing. OT&E, T&E 

C4I system interoperability policy includes no less than 
six explicit policy elements that pertain to 
interoperability testing: (1) interoperability require¬ 
ments testing; (2) Joint C3I Interoperability Database 
with MNSs and ORDs; (3) Joint tests verify 
interoperability in Joint operations; (4) OT&E plans 
include compatibility and interoperability test objec¬ 
tives; (5) TEMPS include compatibility and 
interoperability test objectives; and (6) Test and 
Evaluation (T&E) in all acquisition phases to verify 
interoperability. M&S interoperability policies don’t 
provide any guidance on interoperability testing, even 
though simulations interoperate with one another and 
with C4I systems. This is another glaring omission 
because it is virtually impossible to verify simulation 
interoperability without a similar emphasis on simula¬ 
tion interoperability testing, reporting, and tracking. 

Mapping. Charting. Geodesy Data Standards and 
Specifications 

C4I interoperability policy requires mapping, charting, 
and geodesy data standards to support interoperability. 
Since simulations also use representations of their envi¬ 
ronment, such as maps and terrain databases, there is 
no reason why this policy element should not also 
apply to the M&S domain. 
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Mission Need Statement (MNS) and Operational Re¬ 
quirements Document (ORD) 

C4I interoperability policy requires that the C4I system 
MNS and ORD comply with interoperability policy. It 
also requires the ORD to include: (1) interoperability 
requirements; (2) communications, protocols, and stan¬ 
dards; (3) integration of the system into its architecture; 
(4) Joint use considerations; and (5) procedural and 
technical interfaces. Since a simulation may be a Ma¬ 
jor Automated Information System (MAIS) itself or a 
significant part of an MDAP (Major Defense Acquisi¬ 
tion Program) or another MAIS, there is no reason why 
these policy elements should not also be extended to 
the M&S domain. 

Interoperability Waivers 

C4I interoperability policy explicitly defines the proc¬ 
ess for obtaining a waiver for certification of C4I sys¬ 
tem compatibility, integration, and interoperability. 
There are no comparable policy elements for M&S 
systems. The Navy, however, does have specific crite¬ 
ria for granting waivers for HLA compliance, but it is 
not written down in a policy directive. Clearly, the 
policy for granting waivers should also be explicitly 
stated for the M&S domain. 

4.2.4.1.2 Interoperability Policy Elements in M&S, 
not in C4I 

The following types of interoperability policy elements 
are found in M&S interoperability policy documents, 
but not in C4I policy documents: 

Accreditation 

Why “accreditation “ is used in the M&S domain, 
while “certification” is used in the C4I domain, is not 
completely clear since the two terms seem to be used 
interchangeably. The use of these two terms should be 
standardized and distinctions made in both the C4I and 
M&S domains. 

Common Databases and Tools 

M&S interoperability policy explicitly prescribes 
common databases and tools for model and simula¬ 
tions, while C4I interoperability policy indirectly pre¬ 
scribes them by requiring conformance to the JTA and 
DII COE. As newer C4I systems increasingly utilize 
object-oriented software development techniques, one 
would expect this commonality to extend across both 
domains. 


Data Interchange Standards and Protocols Establish¬ 
ment 

This M&S interoperability policy element is essentially 
the same as two separate, common (C4I and M&S) 
policy elements that require data interchange standards 
and open systems architecture protocols. No policy 
adjustments are needed. 

Data Validation. Verification, and Certification 
(VV&Cl 

Since data verification is not just confined to M&S 
systems, there is no reason why this policy element 
should not be extended to the C4I domain. 

Federations 

These M&S policy elements govern the performance of 
member federates and are applicable to models and 
simulations. When most C4I system software applica¬ 
tions are developed with object-oriented technology 
then it might make sense to extend the application of 
these policy elements to the C4I domain. 

High Level Architecture (HLA) 

M&S interoperability policy elements governing the 
use of HLA are peculiar to models and simulations. 
They have no counterpart in C4I systems, but increas¬ 
ing use of object-oriented software development may 
eventually result in a similar architecture being adopted 
for real time C4I systems, and similar policy elements 
would then be needed. 

Internet Standard and Protocol Establishment 

This M&S interoperability policy element is essentially 
the same as other, similar C4I policy elements, and no 
policy adjustments are required. Internet standards and 
protocols are obviously required for both domains, and 
in some cases both simulations and C4I systems share 
the same internet. 

No-pay / No-play Deadlines for Architecture Confor¬ 
mance 

This M&S interoperability policy element was specifi¬ 
cally introduced to enforce HLA-compliance of simu¬ 
lations. Its equivalent in the C4I domain might be in¬ 
troducing similar deadlines for DII COE conformance, 
but better results would not necessarily be guaranteed 
by setting new deadlines. 
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Object Model Data Dictionary 

M&S interoperability policy elements governing the 
use of object model data dictionaries are peculiar to 
models and simulations. They have no counterpart in 
C4I systems, but increasing use of object-oriented 
software development may eventually result in a 
similar application being adopted for real time C4I 
systems, and similar policy elements would then be 
needed. 

Object Model Template Data Interchange Format 
(OMTDIFj 

M&S interoperability policy elements related to the 
Object Model Template Data Interchange Format 
(OMTDIF) are peculiar to models and simulations. 
They have no counterpart in C4I systems, but increas¬ 
ing use of object-oriented software development may 
eventually result in a similar format being adopted for 
real time C4I systems. 

Risk management 

Risk management in Navy simulations that interface 
with “live” systems, and in some cases, “virtual” simu¬ 
lations, is inferred by SECNAVINST 5200.38 [16], 
which requires close monitoring and higher visibility of 
such simulations. This policy element, however, 
cannot be found in any other M&S or C4I 
interoperability policy directive. These kinds of 
interfaces could potentially result in situations where: 
(1) a real pilot is presented with both real and synthetic 
targets, but can’t differentiate one from the other; (2) a 
real air raid occurs while a ship’s C4I system is 
receiving synthetic targets during an exercise; and (3) a 
real missile launch occurs while a ballistic missile 
defense system is being exercised with synthetic 
missiles. Such dangers strongly suggest that both C4I 
and M&S interoperability policy should completely 
define and emphasize specific requirements for risk 
mitigation in such situations. 

Standard Simulator Data Base Interchange Format 

M&S interoperability policy elements related to the 
Standard Simulator Data Base Interchange Format 
(SIF) are peculiar to models and simulations. They 
have no counterpart in C4I systems, but increasing use 
of object-oriented software development may eventu¬ 
ally result in a similar format being adopted for real 
time C4I systems. 


Synthetic Environment Data Representation Inter¬ 
change Format (SEDRISj 

M&S interoperability policy elements related to the 
Synthetic Environment Data Representation Inter¬ 
change Format (SEDRIS) are peculiar to models and 
simulations. They have no counterpart in C4I systems, 
but increasing use of object-oriented software devel¬ 
opment may eventually result in a similar format being 
adopted for real time C4I systems. 

4.2.4.1.3 Interoperability Policy Elements in both 
C4I and M&S 

Table 4.2.4 also show which types of interoperability 
policy elements are found in both C4I and M&S 
interoperability policy documents by shading those 
policy elements that are common to both domains. 

Interoperability policy elements that are common to 
both the C4I and M&S domains should not present any 
special problems to program managers or system users. 
Instead, they tend to raise questions as to why more 
interoperability policy elements that are unique to ei¬ 
ther the C4I or M&S domain are not common to both 
of them. 

4.2.4.1.4 Interoperability Policy Elements not in 
C4I or M&S 

What may by more important to any thorough 
analysis of interoperability policy elements is not 
revealed by Table 4.2.4 - that is the types of 
interoperability policy elements that are missing 
entirely from interoperability policy directives in both 
domains. Some that are brought to mind by Figure 2.1 
include technology integration, formal interoperability 
theory and modeling, and interoperability performance 
measurement and standards. 

Technology Integration 

Nothing can more quickly render interoperability pol¬ 
icy elements obsolete than major new advances in in¬ 
formation technology. In software development for 
example, “componentware” or software through com¬ 
ponents” promises significant breakthroughs in 
interoperability, but none of the interoperability policy 
directives mention it. Similarly, today’s 

interoperability policy elements do no reflect recent 
improvements in data transfer rates and latency made 
possible by recent advances in data communications 
technology. Some examples include: (1) the use of 
lasers for intra-satellite data transfer rates of 1 GBPS; 
(2) cooled lasers that produce faster, single-wavelength 
optical signals on existing fiber-optic cables at speeds 
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up to 10 trillion BPS; and (3) routers that use only 
mirrors to direet network traffie sixteen times faster 
than eleetrieal switehes do. When interoperability pol- 
iey, sueh as the JTA, mandating the use of older, out¬ 
dated information teehnology standards whieh don’t 
refleet eurrent teehnology advanees, it ean result in the 
program manager and “C4I warrior” being saddled 
with information systems and an infrastrueture that 
provide worse performanee than would otherwise be 
made possible by updated standards. 

The omission of Simulation Based Aequisition (SBA) 
from interoperability poliey doeuments is equally dis¬ 
tressing eonsidering its speeial emphasis in reeent ae¬ 
quisition reform measures. This topie is diseussed ex¬ 
tensively in the Navy Modeling and Simulation Master 
Plan, but is not speeifieally mentioned in any of the 
interoperability poliey doeuments that were analyzed. 

Formal Interoperability Theory & Modeling 

A formal, unified theory of interoperability perform¬ 
anee and related, explanatory models are needed to 
underpin interoperability poliey making in both the C4I 
and M&S domains. Without this formal basis, eom- 
mon performanee measures and metries eannot be used 
to measure and eompare interoperability performanee 
in either domain; and the effeets of ehanges in 
interoperability poliey ean never be known or under¬ 
stood. 

Interoperability Performanee Measurement & Stan¬ 
dards 

Interoperability performanee must be made measurable 
by adopting metries whieh are eommon to both do¬ 
mains, and whieh validate a formal, testable theory of 
interoperability. Only then will it be possible to write 
interoperability performanee standards that ean be used 
by poliey makers to speeify what levels of 
interoperability performanee are aetually aehievable. 
Current interoperability polieies are eonspieuously 
mute on the subjeet of what level of interoperability 
performanee ean or should be aehieved. Without 
quantified performanee goals and eommon measures, it 
is impossible to set realistie goals or know whether 
they’ve been aeeomplished. 

4.2.4.2 Consistency 

“The only completely consistent people are the dead. ” 
- Aldous Huxley 

One view of eonsisteney is eoneemed with faithful and 
aeeurate interpretation and implementation of poliey at 


sueeessively lower organizational levels. A lower- 
level organization must issue speeifie polieies that 
faithfully and aeeurately implement the broader poliey 
statements of a higher eommand authority. 

Reviewed poliey doeuments reeeive their authority and 
mandate from higher management and eommand 
authorities, as shown in the doeument hierarehies de- 
pieted in Figures 4.2.2-1 and 4.2.2-2. 

Another view of eonsisteney deals with the teehnieal 
attributes and details used to deseribe poliey elements 
in eaeh domain. These ineonsisteneies are deseribed in 
greater detail below in Seetion 5.2. 

4.2.5 Interoperability Policy Effectiveness and 
Efficiency 

The effeetiveness and effieieney of interoperability 
poliey eannot be determined beeause no validated the¬ 
ory or models of interoperability performanee eurrently 
exist that explain how interoperability works and what 
eauses interoperability performanee to vary. There are, 
therefore, no assoeiated standard measures or metries 
of interoperability performanee that ean be used to 
gage whether ehanges in interoperability poliey eause 
any pereeptible ehanges in interoperability 
performanee. 

There are some measures and metries of 
interoperability in the C4I domain, but they are largely 
eonfined to message formats and taetieal data link stan¬ 
dards and speeifieations. They do not provide a single, 
quantified, validated measure of interoperability per¬ 
formanee that ean be used in either domain. 


5. Conclusions 

The following eonelusions may be drawn from the 
above diseussion and explanations. 

5.1 Interoperability Policy Completeness 

5.1.1 Interoperability Policy Elements in 
C4I, not in M&S 

As ean be seen in Table 4.2.4, the following types of 
interoperability poliey elements are found in C4I 
interoperability poliey doeuments, but not in M&S 
poliey doeuments: Certifieation and re-eertifieation; 
Compatibility; Doetrine, Integration, Interfaee 
standards; Interoperability problem reporting; 
Interoperability requirements; Interoperability testing. 


14 



OT&E, T&E; Mapping, charting, geodesy data stan¬ 
dards and specifications; Mission Need Statement 
(MNS) and Operational Requirements Document 
(ORD); and Interoperability waivers. 

5.1.2 Interoperability Policy Elements in 
M&S, not in C4I 

As can be seen in Table 4.2.4, types of interoperability 
policy elements found in M&S interoperability policy 
documents, but not in C4I policy documents, include: 
Accreditation; Common databases and tools; Data 
interchange standards and protocols establishment; 
Data VV&C; Federations; High Level Architecture 
(HLA); Internet standard and protocol establishment; 
No-pay / No-play deadlines for architecture 
conformance; Object Model Data Dictionary; Object 
Model Template Data Interchange Format (OMTDIF); 
Risk management (SECNAVINST 5200.38 only); 
Standard Simulator Data Base Interchange Format 
(SIF); and Synthetic Environment Data Representation 
Interchange Format (SEDRIS). 

5.1.3 Interoperability Policy Elements in 
both C4I and M&S 

Table 4.2.4 also show which types of interoperability 
policy elements are found in both C4I and M&S 
interoperability policy documents by shading those 
policy elements that are common to both domains: 
Data interchange standards for application data 
sharing; Defense Information Infrastructure Common 
Operating Environment (DII COE); Human-computer 
interface standards; Information modeling, processing, 
systems security, and transfer standards; Internet 5- 
layer network model; Internet standards and protocols; 
Interoperable with Joint and combined C4I systems and 
operations; Joint Technical Architecture (JTA); Open 
systems architecture standards and protocols; 
Seamless, transparent open systems infrastructure; 
Standard data elements exchanged by C4I systems and 
M&S applications; and Systems design and integration 
mles for technical architecture. 

5.1.4 Interoperability Policy Elements not in 
C4I or M&S 

Interoperability policy elements that are missing from 
both domains include technology integration, formal 
interoperability theory and modeling, and 
interoperability performance measurement and 
standards. System acquisition and Simulation Based 
Acquisition (SBA) interoperability policy elements are 
also conspicuously absent from both C4I and M&S 
interoperability policy documents. 


5.2 Interoperability Policy Consistency 

Interoperability policy documents were found to be 
generally consistent with one another from one organ¬ 
izational level to the next, with the following excep¬ 
tions. 

5.2.1 Policy Focus 

C4I system and M&S policy documents are markedly 
different when it comes to their focus on 
interoperability. Interoperability is a major focus of 
C4I policy documents as evidenced by their higher cor¬ 
relation with interoperability policy concept terms in 
the interoperability policy document database [11, p. 7- 
1]. Interoperability is not a major focus of M&S policy 
documents as evidenced by their lower correlation with 
interoperability policy concept terms in the 
interoperability policy document database [11, p. 7-1]. 

5.2.2 Requirements 

C4I interoperability policy ensures that C4I system 
interoperability requirements: (1) are identified and 
assessed during system requirements (MNS, ORD) 
validation; (2) are documented; (3) meet standards; (4) 
are tested; (5) are validated; (6) are addressed through¬ 
out the system’s life cycle; (7) are a major considera¬ 
tion for MDAP/MAIS start and each milestone deci¬ 
sion; (8) are consistent with C4I system architecture, 
integration requirements, interface standards, and pro¬ 
cedures; and (9) conform to interoperability policy. 
M&S policy does not provide explicit guidance on 
interoperability requirements. The only reference to 
interoperability requirements in M&S policy docu¬ 
ments is in the DoD M&S Master Plan [15]. This 
oversight could result in the failure of simulation/C4I 
system interfaces to provide successful interoperation 
of simulations and C4I systems. 

5.2.3 Standards 

C4I interoperability policy provides message format 
standards, tactical datalink standards, tactical database 
standards, and internet standards. M&S policy pro¬ 
vides architecture standards and internet standards. 
Navy M&S policy [16] is inconsistent in its reference 
to the DIS (Distributed Interactive Simulation) 
standard and technology, instead of HLA (High Level 
Architecture). Neither domain provides an 
interoperability performance standard. Interoperability 
performance standards are needed by policy makers to 
specify what levels of interoperability performance are 
actually achievable. Without quantified performance 
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goals and common measures, it is impossible to set 
realistic goals or know whether they’ve been 
accomplished. 

5.2.4 Interfaces 

Interfaces are explicitly addressed in reviewed C4I 
interoperability policy documents, which require ap¬ 
proved, validated interface standards [11]. Interfaces 
are not explicitly addressed in M&S policy documents. 
It is impossible to assess the effectiveness or efficiency 
of simulation/C4I system interfaces without such inter¬ 
face standards. 

5.2.5 Validated Theory 

A formal, unified theory of interoperability perform¬ 
ance and related, explanatory models are needed to 
underpin interoperability policy making in both the C4I 
and M&S domains. A formal theory of 

interoperability and related explanatory models are not 
now available in either the C4I or M&S domains. It is 
impossible to write a meaningful interoperability per¬ 
formance standard without a sound theoretical basis. 

5.2.6 Performance Metrics & Measurement 

Quantified interoperability performance measures and 
metrics are not available in either the C4I or M&S do¬ 
mains. It is, therefore, impossible to measure and com¬ 
pare interoperability performance in either domain; and 
the effects of changes to interoperability policy can 
never be known or understood. 

5.2.7 Testing 

C4I interoperability policy requires: (1) Test and 
Evaluation (T&E) in all acquisition phases to verify 
interoperability; (2) Test and Evaluation Master Plans 
(TEMPs) and Operational Test and Evaluation (OT&E) 
plans which include compatibility and interoperability 
test objectives; (3) interoperability requirements tests 
that verify interoperability in Joint and combined op¬ 
erations; and (4) DISA maintenance of a database of 
C4I system interoperability requirements and test re¬ 
sults. M&S policy does not include comparable, ex¬ 
plicit interoperability test requirements for the 
interoperability of models and simulations. It is, there¬ 
fore, impossible to assess the effectiveness or 
efficiency of simulation/C4I system interfaces without 
similar, comprehensive testing policy elements. 


5.2.8 Accreditation and Certification 

DISA has certification authority [13] for reporting the 
interoperability of C4ISR systems [11, p. 5-2]. There is 
no certification authority for the interoperability of 
simulation/C4I system interfaces. Certification of 
interoperability of C4I systems is explicitly addressed 
by C4I interoperability policy, but the interoperability 
of M&S systems is not explicitly addressed by DoD, 
Joint, or Navy policy, component level of policy 
document. M&S HLA compliance is addressed by 
M&S policy, but it does not guarantee interoperability 
of one simulation with another, or with a C4I system 
through a simulation/C4I system interface. 

5.2.9 Processes and Procedures 

C4I interoperability policy defines detailed, explicit 
processes and procedures for achieving C4I system 
interoperability, but M&S policy does not. Both the 
C4I and M&S communities have clearly defined or¬ 
ganizational mandates for carrying out policy, but pro¬ 
cesses and procedures are clearer and more precise in 
the C4I domain than they are in the M&S domain. 

5.2.10 Risk Management 

Simulation interfaces with live (real C4I systems) 
simulations or virtual simulations could result in situa¬ 
tions where: (1) a real pilot is presented with both real 
and synthetic targets, but can’t differentiate one from 
the other; (2) a real air raid occurs while a ship’s C4I 
system is receiving synthetic targets during an exercise; 
and (3) a real missile launch occurs while a ballistic 
missile defense system is being exercised with 
synthetic missiles. C4I or M&S interoperability policy 
does not completely define or emphasize specific 
requirements for risk mitigation in such situations. 

6. Recommendations 

The following recommendations are made to improve 
both C4I system and M&S interoperability policy com¬ 
pleteness, consistency, effectiveness, and efficiency. 


6.1 Interoperability Policy Alignment 

Interoperability policy elements in the C4I and M&S 
domains should be aligned with one another to improve 
policy completeness and consistency. 

6.1.1 Interoperability Completeness 
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It is recommended that interoperability policy elements 
in the C4I domain that are not also in the M&S domain 
(see Table 4.2.4) be added to the M&S domain as 
detailed in Sections 4 and 5 above. Similarly, it is 
recommended that interoperability policy elements in 
the M&S domain that are not also in the C4I domain be 
added to the C4I domain. 

6.1.2 Interoperability Consistency 

It is recommended that interoperability policies be 
amended to make interoperability policy elements in 
the C4I and M&S domains consistent with one another 
as prescribed in Section 5.2 above. 

6.2 Interoperability Policy Effectiveness 
and Efficiency 

It is recommended that interoperability performance 
metrics be defined that can be used to measure 
interoperability in both the C4I and M&S domains. It 
is also recommended that these metrics be based upon 
a validated, tested theory of interoperability and 
associated explanatory models. 

It is also recommended that the business process for 
achieving interoperability be formally modeled to pro¬ 
vide a baseline for process improvement in both do¬ 
mains. It is further recommended that the effectiveness 
and efficiency of this process be measured and tracked 
by monitoring changes in interoperability performances 
that result from process improvements or policy 
changes in both domains. 

6.3 Interoperability Program Establish¬ 
ment 

It is strongly recommended that Joint, DoD, and DoD 
component policy makers in both domains adopt a 
common, coordinated interoperability program similar 
to the one depicted by Figure 2.0. Such a program will 
provide a validated, tested theory of interoperability 
and associated, explanatory models, which in turn will 
provide a rational basis for interoperability 
performance metrics and measurement. Metrics and 
measurement will then make it possible to write a 
meaningful interoperability performance standard that 
can then be used as a guide to establish, quantitative 
interoperability performance standards, which in turn 
can be used to rewrite interoperability policy to include 
realistic interoperability goals that are actually 
achievable. 
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